リモートワークとコロケーションワークは単純な二分法ではなく、チームの分散にはいくつかのパターンがあり、それぞれに異なるトレードオフと適切な効果的な手法があります。決定的な証拠を示すことは不可能ですが、私の感覚では、ほとんどのグループはコロケーション環境で作業する方が生産性が高いです。しかし、分散型の作業モデルを使用することで、より生産的なチームを構築することができます。なぜなら、より幅広い人材プールにアクセスできるようになるからです。

ソフトウェアプロジェクトは、ソフトウェア開発の資金調達と組織化の一般的な方法です。一時的な構築のみのチームに作業を組織化し、ビジネスケースで予測される特定のメリットに基づいて資金が提供されます。一方、プロダクトモードでは、永続的なビジネス課題に取り組む、持続的な「構想 - 構築 - 実行」チームを使用します。プロダクトモードでは、チームは迅速に方向転換することができ、エンドツーエンドのサイクルタイムを短縮し、短期的な反復を使用することで実際のメリットを検証できます。同時に、長期的な有効性を維持するために、ソフトウェアのアーキテクチャの整合性を維持します。

理想的な状態では、プロダクトモード組織は、明示的および非明示的なユーザーのニーズに迅速に対応する、疎結合で自律的なチームで構成されます。ただし、複数のチーム間の調整を必要とする機会が発生することがあります。効果的に管理しないと、収益の逸失、顧客の不満、チーム能力の浪費につながります。これらの機会に対応する組織的な取り組みをプログラムと呼びます。この記事では、プロダクトモード組織でプログラムを管理した経験を、失敗したプログラムの例を通して共有します。

プラットフォームチームは、プラットフォームの採用を確実にするために他のチームに独自に依存しています。他のチームのコードベースにコードの変更を組み込むことが、彼らの成功にとって不可欠です。チーム間のコラボレーションにはさまざまなパターンがあり、適切なものを選択するには、プラットフォームの採用段階と、両方のチームとコードベースが外部からの影響を受け入れる能力の両方によって異なります。

コンウェイの法則（1968年にメルヴィン・コンウェイによって定式化）は、システムの設計は設計者のコミュニケーションパターンによって制約されると述べています。ブリギッタ、マイク、ジェームズ、そして私は、この原則の意味と、キャリアの中でそれがどのように展開してきたかについて話し合います。マイクロサービスの概念、ビジネス機能との連携の重要性、逆コンウェイ操作の役割について説明します。

モジュール式アーキテクチャはソフトウェアデリバリーを改善できますか？はい！-ただし、いくつかの注意点があります。この記事では、成長痛を軽減するために、アーキテクチャをよりモジュール式に移行しようとした企業の歩みを説明します。モジュール性は、アーキテクチャだけでなく、ビジネスコミュニケーション、チームトポロジー、効果的な開発者エクスペリエンスにまで及ぶ多面的なソリューションであることがわかりました。これらの要素に細心の注意を払うことで、企業はモバイルアプリケーションのデリバリーパフォーマンスを大幅に向上させることができました。

重要なソフトウェア開発作業では、分析、ユーザーエクスペリエンス設計、開発、テストなど、いくつかの異なるアクティビティが発生する必要があります。アクティビティ指向のチームは、これらのアクティビティを中心に編成されるため、ユーザーエクスペリエンス設計、開発、テストなどのための専任チームがあります。アクティビティ指向は多くのメリットをもたらすと約束しますが、ソフトウェア開発は通常、成果指向のチームで行う方が適切です。

アライメントマップは、進行中の作業とビジネス成果との連携を可視化するのに役立つ組織情報ラジエーターです。作業は、通常の機能追加や、再構築、技術的負債の返済、構築およびデプロイパイプラインの改善などの技術的な作業である場合があります。チームメンバーは、アライメントマップを使用して、日々の作業がどのビジネス成果を改善するためのものであるかを理解します。ビジネスおよびITスポンサーは、進行中の作業が自分たちが関心のあるビジネス成果とどのように関係しているかを理解するために使用します。

ソフトウェア開発の未解決の問題の1つは、ソフトウェアの一部がどのような境界を持つかを決定することです。（ブラウザはオペレーティングシステムの一部ですか、そうでないですか？）サービス指向アーキテクチャの多くの支持者は、アプリケーションがなくなるだろうと信じています。したがって、将来のエンタープライズソフトウェア開発は、サービスを一緒に組み立てることになるでしょう。

アプリケーション境界を描くのが非常に難しいのと同じ理由で、アプリケーションはなくなると思いません。基本的に、アプリケーションは社会的な構造物です。

バイモーダルITは、ソフトウェアシステムを管理と制御のためにこれら2つの異なるカテゴリに分割する必要があるという欠陥のある概念です。

• フロントオフィスシステム（エンゲージメントシステム）は、迅速な機能開発に最適化する必要があります。これらのエンゲージメントシステムは、変化する顧客ニーズとビジネスチャンスに迅速に対応する必要があります。欠陥は、この迅速な開発サイクルのために必要なコストとして許容される必要があります。
• バックオフィスシステム（記録システム）は、信頼性を最適化する必要があります。記録システムとして、企業に損害を与える欠陥が発生しないことが重要です。したがって、変更速度を遅くします。

境界コンテキストは、ドメイン駆動設計の中心的なパターンです。これは、大規模なモデルとチームを扱うことを目的としたDDDの戦略的設計セクションの焦点です。DDDは、大規模なモデルを異なる境界コンテキストに分割し、それらの相互関係を明示的にすることで、大規模なモデルを処理します。

ビジネス機能中心のチームは、その作業がビジネスの特定の領域に長期的に調整されているチームです。チームは、当該ビジネス機能がビジネスに関連している限り存在します。これは、プロジェクト範囲を提供するために必要な期間しか存続しないプロジェクトチームとは対照的です。

私がこれまで見てきたコードオーナーシップには、さまざまなスキームがあります。それらを3つの大まかなカテゴリに分類します。

ソフトウェアアーキテクチャで私が支持する実務家のほとんどは、この分野における一般的な法則には深く懐疑的です。優れたソフトウェアアーキテクチャは非常にコンテキスト固有であり、幅広い環境で異なる解決策が得られるトレードオフを分析します。しかし、彼らがすべて同意するものが1つあるとすれば、それはコンウェイの法則の重要性と力です。私がこれまで見てきたすべてのシステムに影響を与えるほど重要であり、それに立ち向かおうとすると敗北する運命にあるほど強力です。

一流のエンタープライズソフトウェア開発者を構成するものを検討するとき、会話はフレームワークや言語の知識、あるいは複雑なアルゴリズムやデータ構造を理解する能力に移行することがよくあります。私にとって、プログラマー、そして実際には開発チームにおいて最も重要な特性の1つは、顧客親和性と呼ぶものです。これは、ソフトウェアが対処しているビジネス上の問題、およびそのビジネスの世界に住んでいる人々に対する開発者の関心と親密さです。

アジャイルソフトウェア開発は、要件分析、テスト、開発の間のサイロを一部解消しました。デプロイ、運用、保守は、ソフトウェア開発プロセスの残りの部分から同様の分離を経験してきた他の活動です。DevOpsムーブメントは、これらのサイロを取り除き、開発と運用の間のコラボレーションを促進することを目的としています。

一般的な質問は、大規模なプロジェクトをアジャイル手法で実行できるかどうかです。結局のところ、多くのアジャイルアプローチは小規模なプロジェクト向けに設計されており、抵抗する重量級のアイデアは、より大きなプロジェクトでより必要とされます。

私はレイプログラマーという用語を、自分自身をプログラマーだとは思わずにプログラミングをしている人を意味するために使用します。1日の大部分をスプレッドシートで作業している人は、プログラミングを行っており、しばしば非常に集中的なプログラミングを行っています。ただし、通常、彼女は自分自身をプログラマーとは呼ばず、プログラミングを上達させる方法を学ぶために多くの時間を費やすとは考えていません。

ソフトウェア開発のスポンサーは、通常、ベロシティや本番環境へのデプロイ頻度などの開発指標にはあまり関心がありません。彼らがより重視するのは、ソフトウェアがもたらすビジネス上のメリット、例えば、手作業の削減、販売コンバージョンの向上、顧客満足度の向上など、つまりビジネス成果です。成果志向のチームとは、ビジネス成果を出すことが義務付けられ、そのための能力を備えたチームであり、成果を実現するために必要なすべての活動を実行できる人材がいます。対照的に、活動志向のチームは、成果を出すための装備も義務もありません。彼らは、成果を出すために必要な複数の活動のうちの1つしか実行できません。

ペアプログラミングに関するよくある誤解について。

コミュニケーション技術の向上により、リモートファーストスタイルで働くチームが増加しており、この傾向はCovid-19パンデミックによる強制的な隔離によってさらに加速しました。しかし、リモートで運営するチームでも、対面での集まりは依然として有益であり、数ヶ月ごとに行うべきです。

採用の場面を想像してください。どちらも数年の経験を持つ2人の候補者がいます。青コーナーには、あなたが好むスタイルの優れた広範な設計スキル（私の場合、それはDRY、パターンを慎重に使用、TDD、コミュニケーションの良いコードなどですが、実際の一覧は重要ではありません。重要なのは、それがあなたの好みであるということです）を持っている人がいます。しかし、彼女はあなたが使用している特定のプラットフォームテクノロジーについては何も知りません。赤コーナーには、これらの問題にほとんど知識（または関心）がないものの、あなたのプラットフォームをよく知っている人、つまり言語のエッジケース、利用可能なライブラリ、ツールを自然に使いこなせる人がいます。他のすべてが同じである（これは、このような思考実験以外では決してありません）と仮定し、あなたのチームにはこの候補者が埋める可能性のある大きな穴がないとします。どちらを優先しますか？

ソフトウェアの良いところの1つは、人々がそれを欲しがり、すぐに欲しがることです。組織がソフトウェアの生産を加速するようにチームに求めるのは普通であり、時々組織はコミットメントを示す方法として、チームに人員を追加するためにお金を使うことで支援しようとします。

情報量の多いプログラムをモジュール化する最も一般的な方法の1つは、プレゼンテーション（UI）、ドメインロジック（ビジネスロジックとも呼ばれる）、およびデータアクセスの3つの広範なレイヤーに分離することです。そのため、Webアプリケーションは、HTTPリクエストの処理とHTMLのレンダリングについて知っているWebレイヤー、検証と計算を含むビジネスロジックレイヤー、データベースやリモートサービスでの永続データの管理方法を整理するデータアクセスレイヤーに分割されているのをよく見かけます。

私は過去1年間、Thoughtworksをあちこちと歩き回り、多くのプロジェクトで多くの人々と話をしてきました。私に強く印象付けられたメッセージの1つは、ローテーションの価値です。

先週、私はフロリダをあちこちと歩き回り、Microsoftのアーキテクチャカウンシルでダン・サンドリンとデビッド・ルブランと話す機会を得ました。デビッド・ルブランを知らない人のために説明すると、彼はマイケル・ハワードと共に非常に人気のある書籍Writing Secure Codeを執筆しました。各セッションで、私はP of EAA（これは今週JavaWorldの賞を受賞しました）に関する講演と質疑応答を行い、デビッドはセキュリティについて講演を行いました。

企業コンピューティングのニーズが、効果的なコラボレーションを可能にするためにお互いにサービスを提供する多くの小さなアプリケーションに分割されている、非常に幸せなSOAの世界を想像してみましょう。ある朝、コンシューマーサービスはサプライヤーサービスからいくつかの情報を必要としています。問題は、サプライヤーサービスにはこの情報を取得するために必要なデータと処理ロジックがあるにもかかわらず、サービスインターフェイスを介してその情報をまだ公開していないということです。サプライヤーには潜在的なサービスがありますが、実際にはまだ存在していません。

最近のコードオーナーシップに関する投稿で、私はコードオーナーシップの問題について考えている方法を説明しました。私のソフトウェア開発の友人の多くはエクストリームプログラマーであり、集団的なコードオーナーシップを好む傾向があります。ただし、これらの種類のプラクティスは絶対的なものではなく、常にローカルな考慮事項によって緩和される必要があります。私の同僚の1人が、XPの強力なファンであってもプラクティスを変化させる必要がある場合を示す良い事例として、次の話を私に送ってくれました。（彼は自分のチームについて話しているので、匿名を希望しています。）

ソフトウェア開発を、コードを丁寧に作成することから、コンポーネントの簡単な組み立てによって強力なシステムを構築することに変えるという考え方は、私がこの業界に入って以来の目標です。それは時々垣間見られる目標ですが、決して本当に達成されていません。多くのテクノロジーが産業上の再利用というニンジンをぶら下げていますが。

大企業向けのソフトウェア資産など、大規模なソフトウェア開発には多くの人員が必要です。また、多くの人員がいる場合は、それらを効果的なチームに分割する方法を考える必要があります。ビジネスケイパビリティ中心のチームを編成すると、ソフトウェア開発が顧客のニーズに対応しやすくなりますが、必要なスキルの範囲が広すぎて、そのようなチームを圧倒することがよくあります。チームトポロジーは、マシュー・スケルトンとマヌエル・パイスによって開発された、ソフトウェア開発チームの編成を記述するためのモデルです。これは、4つの形式のチームと3つのモードのチームインタラクションを定義します。このモデルは、ビジネスケイパビリティ中心のチームが価値のあるソフトウェアの安定した流れを提供するというタスクにおいて繁栄できるように、健全なインタラクションを促進します。

モバイルアプリケーションは、ここ数年、ソフトウェア開発において注目を集めているアイテムです。多くのソフトウェアデリバリー企業と同様に、Thoughtworksはクライアントからモバイルアプリケーションを構築してほしいという多くのリクエストを受けています。しかし、ほとんどの場合、企業が私たち（または誰か）にモバイルアプリケーションを構築するように依頼する場合、彼らは間違ったスタートを切っています。ほとんどの場合、ユーザーにモバイルデバイスで操作してもらいたい場合でも、モバイルアプリケーションを構築することを決して考えるべきではありません。代わりに、モバイル、デスクトップ、タブレットなど、ユーザーが使用する可能性のあるデバイスを横断して表示される単一のアプリケーションを構築することを考える必要があります。

ツーピザチームとは、特定のビジネスケイパビリティ向けのソフトウェアを完全にサポートする小さなチームのことです。この用語は、Amazonがソフトウェアスタッフを組織する方法を説明するために使用されるようになったことで普及しました。

私のキャリアを通して見てきた一貫したテーマの1つは、ソフトウェア開発の性質と重要性です。数年前、見込み客の1人が営業担当者に「ソフトウェアは下水管のようなもので、確実に動作してほしいし、詳細については知りたくない」と言いました。これは、ニコラス・カーがIT Doesnt Matterで語ったアプローチです。対照的に、ITがビジネスのより明確な戦略的イネーブラーとして機能し、新しい市場への参入や市場シェアの大幅な増加を可能にした多くの企業に対して、私たちは仕事をしてきました。では、ITは下水管のようなユーティリティなのか、それとも戦略的資産なのでしょうか？